home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970929-19971216
/
000257_news@newsmaster….columbia.edu _Thu Nov 13 12:46:58 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-12-15
|
9KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA25186
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 13 Nov 1997 12:46:57 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA03173
for kermit.misc@watsun; Thu, 13 Nov 1997 12:46:57 -0500 (EST)
Path: news.columbia.edu!panix!logbridge.uoregon.edu!su-news-hub1.bbnplanet.com!news.bbnplanet.com!news1.best.com!noos.hooked.net!news.scruz.net!usenet
From: Jon Shemitz <jon@midnightbeach.com>
Newsgroups: alt.lang.delphi,aus.electronics,comp.dcom.modems,comp.home.automation,comp.lang.pascal.delphi.misc,comp.protocols.kermit.misc,sci.electronics.design
Subject: Re: Xmodem specs required
Date: Thu, 13 Nov 1997 09:31:31 -0800
Organization: Midnight Beach
Lines: 153
Message-ID: <346B3973.244AB2B0@midnightbeach.com>
References: <64f01j$cno@granny.mac.co.nz>
Reply-To: jon@midnightbeach.com
NNTP-Posting-Host: 165.227.113.198
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.02 [en] (Win95; U)
To: huisman <minilinx@netaccess.co.nz>
Xref: news.columbia.edu alt.lang.delphi:19542 aus.electronics:8562 comp.dcom.modems:204910 comp.home.automation:36058 comp.lang.pascal.delphi.misc:131315 comp.protocols.kermit.misc:8040 sci.electronics.design:59280
huisman wrote:
> I'm not sure which is best group for data communications but
> does anyone have information regarding Xmodem protocol.
> I am wanting to write 8051 code for data logger to communicate
> with PC.(PC end will be Win 95 (Delphi 2 ) app.
MODEM/XMODEM Protocol Explained
by
Kelly Smith, CP/M-Net "SYSOP"
January 8,1980
I thought that it may be of some interest to those of you that use the
MODEM/XMODEM file transfer capability of the CP/M-Net, to get a little
insight as to the communications protocol (i.e. "handshaking method") used
by the system.
Herein lies the details of a very good (not perfect) data communications
protocol that has become the "de facto" standard for various remote CP/M
systems (RCPM's) that are accessible across the country (refer to RCPMLST4.DOC
on all RCPM's for access numbers and note that the "digit number" in that
list changes as new system are listed). I also wish to give credit to Ward
Christensen (the "original" CBBS) for writing MODEM.ASM (CPMUG Volume 25.11)
and Keith Petersen, Bruce Ratoff, Dave Hardy, Rod Hart, Tom "C" (we know who
you are Tom!), and others, for enhancements to Ward's original program that
we now call XMODEM (external modem).
Data is sent in 128 byte blocks with sequentially numbered blocks, and
appended by a single checksum at the end of each block. As the receiving
computer acquires the incoming data, it performs it's own checksum and upon
each completion of a block, it compares it's checksum result with that of
the sending computers. If the receiving computer matches the checksum of
the sending computer, it transmits an ACK (ASCII code protocol character for
ACKNOWLEDGE (04 Hex, Control-F)) back to the sending computer. The ACK
therefore means "alls well on this end, send some more...". Notice in
the following example, that the sending computer will transmit an "initial
NAK" (ASCII protocol character for NEGATIVE ACKNOWLEDGE (15 Hex,
Control-U))...or, "that wasn't quite right, please send again". Due to the
asynchronous nature of the initial "hook-up" between the two computers,
the receiving computer will "time-out" looking for data, and send the NAK
as the "cue" for the sending computer to begin transmission. The sending
computer knows that the receiving computer will "time-out", and uses this
fact to "get in sync"...The sending computer responds to the "initial NAK"
with a SOH (ASCII code protocol character for START OF HEADING (01 Hex,
Control-A)), sends the first block number, sends the 2' complement of the block
number (VERY important, I will discuss this later...), sends 128 bytes of 8 bit
data (thats why we can transfer ".COM" files), and finally a checksum,
where the checksum is calculated by summing the SOH, the block number, the
block number 2's complement, and the 128 bytes of data.
Receiving Computer:
----/NAK/------------------------/ACK/----------------------
15H 06H
Sending Computer:
--------/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
01H 001H 0FEH 8bit 8bit 01H 002H 0FDH 8bit ....
This process continues, with the next 128 bytes, IF the block was ACK'ed
by the receiving computer, and then the next sequential block number and
it's 2's complement, etc.
But what happens if the block is NAK'ed?...easy, the sending computer
just re-sends the previous block. Now the hard part...what if the sending
computer transmits a block, the receiving computer gets it and sends an ACK,
but the sender does not see it?...The sending computer thinks that it has
failed and after 10 seconds re-transmits the block...ARGH!...the
receiving computer has "stashed" the data in memory or on disk (data is
written to disk after receiving 16 blocks), the receiving computer is now 1
block AHEAD of the transmiting computer! Here comes the operation of the block
numbers...The receiver detects that this is the last block (all over again),
and transmits back an ACK, throws away the block, and (effectively)
"catches up"...clever! Whats more, the integrity of the block number is
verified by the receiving computer, because it "sums" the SOH (01 Hex) with
the block number plus the 2's complement of the block number), and the
result MUST BE zero for a proper transfer (e.g. 01+01+FE hex = 00, on
the first block). The sequence of events then, looks like this:
Receiving Computer:
----/ACK/-----------------------/NAK/-----------------------
06H 15H
Sending Computer:
CSUM/---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
8bit 01H 003H 0FCH 8bit 8bit 01H 003H 0FCH 8bit ....
Normal completion of data transfers will then conclude with an EOT (ASCII
code protocol END OF TRANSMISSION, 04 Hex, Control-D) from the sending
computer, and a final ACK from the receiving computer. Unfortunately, if
the receiving computer misses the EOT, it will continue to wait for the
next block (sending NAK's every 10 seconds, up to 10 times) and eventually
"time-out". This is rarely the case however, and although not
"bullet-proof", it is a very workable protocol.
Receiving Computer:
----/ACK/---/ACK/"Transfer Complete"/A>(or B>)
06H 06H ................................
Sending Computer:
CSUM/---/EOT/---/A>(or B>)
8bit 04H .............
In some case, where the telephone transmission is repeatedly
"trashed" (weak signals, multiple noise "hits", etc.), the receiving
computer (and operator) will be provided the option to quit. Here, the
operator enters "R" or "Q" in response to "Retry or Quit?" (after 10
retries), and if quit is envoked by the operator, a CAN (ASCII code protocol
CANCEL, 18 Hex, Control-X) is sent by the receiving computer to cancel the
entire transfer session (Note: is is possible to "garble" an ACK to a
CAN, and abort prematurley):
Receiving Computer:
----/NAK/...NAK's ten times.../"Retry or Quit?"(Q)/CAN/A>...
15H 18H
Sending Computer:
CSUM/---/...Garbled Data....../-----------------------/A>...
8bit
A final considerations when using the MODEM program, is a timing related
problems when transfer status messages and/or textual data is directed to the
screen of a slow (4800 Baud or less) terminal or to a hard copy printer. This
problem is readily apparent (multiple NAK's) when using MODEM for the first
time, and can usually be "cured" by NOT SPECIFYING the "V" (video) sub-option
when sending or receiving files. Users of Lifeboat Associates BSTAM
encounter the same problem, but this is easily fixed with the files
TQPATCH.ASM and RQPATCH.ASM (transfer quiet/receive quiet) that Keith
Petersen (Royal Oak CP/M, "call-back" remote system, (313)- 588-7054) wrote
to solve the problem of low speed terminal I/O.
For users of CBBS's that do not have MODEM.ASM (but DO HAVE a CP/M disk
system...ESSENTIAL!), let me suggest that you "data capture" the file
MBOOT3.ASM from one of the RCPM's (it's a small 8 kilo-byte file that "fits"
in most system's memory) to get the larger MODEM.ASM (40 kilo-bytes). Check
it very carefully for errors using the "data capture" (read ERROR PRONE
method here). Then edit and assemble for your modem configuration.
If you are tired of buying software where the advertisment is written better
than the program, then the RCPM's are just what you have been looking for...and
FREE!